Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as data frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
Multiple Virtual Local Area Networks (VLANs) may be implemented on a given set of interconnected network elements to enable sub-groups of users to communicate with each other. For example, an enterprise network may have an Ethernet local area network (LAN) deployed to enable data and optionally voice communication to occur within the enterprise. One or more VLANs may be run on top of the this Ethernet network to enable different groups to communicate with each other on the network. As a simple example, the enterprise may have an untrusted VLAN that users are allowed to connect to prior to authentication, and a trusted VLAN that the users are allowed to connect to after authentication processes have been completed. In this way both secure and unsecured communications can occur on the same Ethernet network.
Implementation of VLANS on an Ethernet network is enabled by IEEE 802.1Q, which enables a Q-tag containing a VLAN ID to be added to the Ethernet frame header. By tagging traffic with the appropriate VLAN ID, the traffic may be separated into multiple VLANS on the same underlying Ethernet network.
When a computer or other device connects to a communication network, it will undergo authentication/authorization processes to determine the type of privileges it should be granted on the network. In addition, an Internet Protocol address will be assigned to the computer/other device. The Internet Protocol address enables other devices on the network to route traffic to the computer/device.
Some Ethernet switches are constructed such that there is a built-in assumption that each VLAN on the Ethernet network will be associated with at most one class C IP address subnet, e.g. 192.168.10.1/24. This limits the number of computers per VLAN to the number of addresses within the subnet. In a typical IP subnet, with approximately 250 IP addresses, the number of users that may connect to the VLAN is thus limited to approximately 250.
As the number of computers/devices supported by a given Ethernet switch increases, it may be desirable to have more than one subnet associated with a given VLAN. The process of associating IP addresses from multiple IP subnets with the same VLAN will be referred to herein as “IP Multinetting”. For example, a large office building may have 500 or more people working on the same floor, supported by a given Ethernet switch, who would all like to be part of the same VLAN. Since a given IP subnet is limited to approximately 250 IP addresses, the workers will need to be assigned IP addresses from more than one IP subnet. Hence, if these workers are all to be part of the same VLAN, the Ethernet switch will need to be able to associate IP addresses from more than one IP subnet with a given VLAN.
Although some Ethernet switches have been built to support IP Multinetting, unfortunately, as noted above, some Ethernet switches are not built to support this feature. Indeed, the one-to-one association between IP subnet and VLAN may pervade the underlying operating code within the control plane and even be hard coded into the data plane (fastpath) of the Ethernet switch. Thus, in a switch of this nature, from a layer 3 perspective, only IP addresses from one IP subnet will be populated into the routing tables (Forwarding DataBase or FDB) for a particular VLAN ID. Stated differently, the Forwarding Database (FDB) for the VLAN will only contain IP addresses from a particular IP subnet. Thus, only packets addressed to IP addresses within the particular IP subnet will be able to be transmitted over the VLAN on the Ethernet network.
Although it may be possible to redesign the operating code and fastpath at great cost, a more optimal solution would be to find a way to overcome this limitation so that the Ethernet switch could support IP multinetting without modifying the underlying infrastructure.